(4) 迷思

接下來三天，我會分享在實踐 Velocity 的三個迷思與對應的學習。

迷思之一：執迷不悟的指標陷阱

在前面分享 Velocity 的故事裡，其實會發現隨著開發情境的變動，在使用這個指標就會越加繁重才能達到與原本相近的效果。明明越來越難用了，卻不放手，這是為什麼呢？

我自己反思的原因有幾個：

• 過於相信這個指標
• 只知道這個指標能夠有這樣的效果
• 最佳化的誘惑

過分相信這個指標

指標對你來說的用途為何？筆者在〈第四章　如何現形流動順暢度？〉曾講到這個概念。指標對檢視者來說是判讀、還是判決？當時建議的是判讀。

指標只是一個參考用的情報，它無法解釋所有事情。甚至像是 Velocity 這樣的指標，他其實已經是很後期的落後指標（Lag Measure），他是被交付量與時間週期長度所影響，而交付量又被很多原因給影響。這個指標背後的情報是複雜的，所以參考價值的穩定度也是可能會隨情境變動的。

為了避免掉入這樣的陷阱，對任何指標都應該秉持著它只是個情報，當發現這個情報參考價值變低時，就應該去調整或是捨棄這個情報來源，而不該執迷不悟的去相信靠這個指標就一定能現形開發流動的狀態。

只知道這個指標能夠有這樣的效果

當一個問題，解決方案只有一個選項，就不沒有選擇，連不要的選項都沒有，只能被迫接受。

多數在敏捷開發的情境裡，只知道可以透過 Velocity 現形開發流動，可以協助預測未來的開發排程。就算 Velocity 變得很難用，但至少還是可以參考的指標，如果不繼續使用，那就連可以參考的標的都沒有了。在這樣的情況，面對想要達到某個目的的情況，只能硬著頭皮繼續用下去了。

但有時候其實只是因為當知道一個解法後，很容易就停下來探索其他的可能性。

最佳化的誘惑

這是我感受最深的一個原因了，身為一個工程師，當發現一個解決方案有問題時，通常都會認為是這個解決方案還不夠好，應該要持續最佳化，並以能改進他為傲。但是有時候投入大量的資源去最佳化，還不如換一個解法帶來的效益。

就像前面分享的經驗，發現 Velocity 開始有需求時，我其實就掉進了解題的愉悅感裡面，認為應該要打造一個更好的解決方案，於是加了許多新的數據與計算。問題被滿足了，但其實滿足的早已不是當初 Velocity 想解決的問題了。

小結

看到數字，意外的會給人一種安心感，好像接下來的認知都有憑有據，這就是指標讓人執迷不悟的陷阱。這些都會導致現形開發流動的設備開始失準，卻不自知。就像是壞掉的儀表板，看起來有在跑，至於顯示的是不是對的，鮮少人會去覺察與質疑。

希望透過這樣的學習，能讓讀者在面對指標時，能夠好好思考適用性，而不是一昧的直接採納，甚至拿來作為判決團隊表現的生死狀。